Industry increasingly depends upon highly automated data acquisition and control systems to ensure that industrial processes are run efficiently and reliably while lowering their overall production costs. Data acquisition begins when a number of sensors measure aspects of an industrial process and report their measurements back to a data collection and control system. Such measurements come in a wide variety of forms. By way of example the measurements produced by a sensor/recorder include: a temperature, a pressure, a pH, a mass/volume flow of material, a counter of items passing through a particular machine/process, a tallied inventory of packages waiting in a shipping line, cycle completions, etc. Often sophisticated process management and control software examines the incoming data associated with an industrial process, produces status reports and operation summaries, and, in many cases, responds to events/operator instructions by sending commands to actuators/controllers that modify operation of at least a portion of the industrial process. The data produced by the sensors also allow an operator to perform a number of supervisory tasks including: tailor the process (e.g., specify new set points) in response to varying external conditions (including costs of raw materials), detect an inefficient/non-optimal operating condition and/or impending equipment failure, and take remedial action such as move equipment into and out of service as required.
A very simple and familiar example of a data acquisition and control system is a thermostat-controlled home heating/air conditioning system. A thermometer measures a current temperature, the measurement is compared with a desired temperature range, and, if necessary, commands are sent to a furnace or cooling unit to achieve a desired temperature. Furthermore, a user can program/manually set the controller to have particular setpoint temperatures at certain time intervals of the day.
Typical industrial processes are substantially more complex than the above-described simple thermostat example. In fact, it is not unheard of to have thousands or even tens of thousands of sensors and control elements (e.g., valve actuators) monitoring/controlling all aspects of a multi-stage process within an industrial plant. The amount of data sent for each measurement and the frequency of the measurements varies from sensor to sensor in a system. For accuracy and to facilitate quick notice/response of plant events/upset conditions, some of these sensors update/transmit their measurements several times every second. When multiplied by thousands of sensors/control elements, the volume of data generated by a plant's supervisory process control and plant information system can be very large.
Specialized process control and manufacturing/production information data storage facilities (also referred to as plant historians) have been developed to handle the potentially massive amounts of process/production information generated by the aforementioned systems. An example of such system is the WONDERWARE IndustrialSQL Server historian. A data acquisition service associated with the historian collects time series data from a variety of data sources (e.g., data access servers). The collected data is thereafter deposited with the historian to achieve data access efficiency and querying benefits/capabilities of the historian's relational database. Through its relational database, the historian integrates plant data with event, summary, production and configuration information.
Traditionally, plant databases, referred to as historians, have collected and stored in an organized manner to facilitate efficient retrieval by a database server (i.e., tabled) streams of time stamped data representing process/plant/production status over the course of time. The status data is of value for purposes of maintaining a record of plant performance and presenting/recreating the state of a process or plant equipment at a particular point in time. Over the course of time, even in relatively simple systems, Terabytes of the streaming time stamped information are generated by the system and tabled by the historian.
The tabled information is thereafter retrieved from the tables of historians and displayed by a variety of historian database client applications including trending and analytical applications at a supervisory level of an industrial process control system/enterprise. Such applications include displays for presenting/recreating the changing state of an industrial process or plant equipment at any particular point (or series of points) in time. A specific example of such client application is the WONDERWARE ActiveFactory trending and analysis application. This trending and analysis application provides a flexible set of display and analytical tools for accessing, visualizing and analyzing plant performance/status information.
It is generally desirable to accumulate/record time-series information representative of the current status of an industrial/manufacturing process from many points. The combination of frequent sampling for a large number of points could potentially overwhelm the storage capacity of a historian. At the very least, the presence of such massive volumes of data could potentially slow down access times and render computer hardware prematurely obsolete.
Data point compression can be used to reduce the quantity of stored (and subsequently displayed) data used to create the segments of a line graph in a trending application output. In contrast to averaging (taking the average of a set of samples within a period of time) or filtering (suppressing transient spikes) operations, data compression analyzes the signal of a data stream (i.e., the relationships between the neighboring point values) to abstract the critical aspects from the time-series point values. The abstraction effort is intended to keep the important aspects of the “signal” represented by the time-series point values while reducing the number of stored points. It is noted that the compression technique disclosed herein is intended to compliment, rather than displace, averaging and filtering data reduction techniques.
Techniques have been previously proposed for reducing/compressing the volume of data stored within a historian database. In a first method, described in Bristol, U.S. Pat. No. 4,669,097, a “swinging door” data compression method is disclosed. In the “swinging door” compression method, a set of received data points are used to define a “corridor”. In particular, the corridor is defined by an initial reference point, a specified set of offsets and a slope defined by a swinging door algorithm (see, FIG. 3). Upon receiving a first data point falling outside the defined corridor, an endpoint of the corridor is established. The two endpoints of the completed corridor are kept. The received data points falling within the two endpoints of the defined corridor are discarded. The end of a corridor is established when a value is found to be outside the established corridor. At this point the last point within the corridor as well as the first point outside the corridor are recorded, and construction of a new corridor commences with the last point within the completed corridor. The resulting set of saved points representing the trend graph correspond to the endpoints of the corridors. The aim of the Bristol '097 patent is to reduce, through refinement of the corridor definition as subsequent points are received, the overall number of points stored while maintaining a satisfactory record of a trending line segment signal for a time-series set of data points. The swinging door compression algorithm initially disclosed in the Bristol '097 patent was subsequently refined to allow for a variable set of offset values. This variation of the swinging door algorithm was disclosed in Bristol U.S. Pat. No. 5,774,385.